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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2006). 

Abstract 
This document serves to register and document the standard MIME types 
associated with the 3GPP2 multimedia file format, which is part of 


the family based on the ISO Media File Format. 
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1. Introduction 


The third-generation partnership project 2 (3GPP2) for 3rd generation 
cellular telephony has defined a standard file format to contain 
audio/visual sequences that may be downloaded to cellular phones 
[3gpp2]. At the time of writing, the 3GPP2 file format (3G2) can 
contain H.263, H.264, or MPEG-4 video; and 13K Vocoder, EVRC or AMR 
Narrow-band speech, or AAC audio; and 3GPP timed text. 
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Within the file, as with all files in the ’ISO’ family, there is an 
intrinsic file-type box, which identifies those specifications to 
which the file complies, and which players (possibly compliant with 
only one specification) are permitted by the content author to play 
the file. This identification is through four-letter ’brands’. 
Files identified by the MIME [MIME1] type defined in this document 
MUST contain, in their compatible brands list, a brand defined ina 
standard (issued by 3GPP2) that can apply to 3GPP2 files. 


The MIME types defined in this document are needed correctly to 
identify such files when they are served over HTTP, included in 
multi-part documents, or used in other places where MIME types are 
used. 


1.1. Conventions Used in This Document 


In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" are to be interpreted as described in RFC 2119 
[RFC2119]. 


2. Security Considerations 


The 3GPP2 file format may contain audio, video, and displayable text 
data. There is currently no provision for '’active’ elements (such as 
scripts) of any kind. 


Clearly, it is possible to author malicious files that attempt to 
call for an excessively large picture size, high sampling-rate audio, 
etc. However, clients can and usually do protect themselves against 
this kind of attack. 


It should be noted that selected metadata fields may encompass 
information partly intended to protect the media against unauthorized 
use or distribution. In this case, the intention is that alteration 
or removal of the data in the field would be treated as an offense 
under national agreement-—based World Intellectual Property 
Organization (WIPO) treaties. 


3GPP2 files have an extensible structure, so it is theoretically 
possible that metadata fields or media formats could be defined in 
the future that could be used to induce particular actions on the 
part of the recipient, thus presenting additional security risks; but 
this type of capability is currently not supported in the referenced 
specification. 
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Encryption, signing, or authentication of these file formats can be 
done using any media-independent transformations of the file or media 
data. 

3. MIME Types 


This registration applies to all files defined as using the ’3G2’ 

file format and identified with a suitable brand in a 3GPP2 

specification. The usual file suffix for all these files is ".3g2". 
3.1. Files with Audio but No Video 


The type "audio/3gpp2" may be used for files containing audio but no 
visual presentation (neither video nor timed text, for example). 


To: ietf-types@iana.org 
Subject: Registration of Standard MIME media type audio/3gpp2 


MIME media type name: 


audio 
MIME subtype name: 
3gpp2 
Required parameters: 
None. 
Optional parameters: 
Codecs. See [Bucket]. If the audio/3gpp2 body part contains 


another container format, the Codecs parameter MUST list all 
codecs indicated by all formats, including any contained formats. 
Optional parameter values: 
[3gpp2] 
Encoding considerations: 
This data is binary and should be transmitted in a suitable 
encoding without CR/LF conversion, 7-bit stripping, etc.; base64 
is a suitable encoding. Note that this MIME type is used only 
for files; separate types are used for real-time transfer, such 
as for the RTP payload format for 13K vocoder speech [RFC2658]. 
Security considerations: 
See the security considerations section in RFC 4393 (this 
document). 
Interoperability considerations: 
The 3GPP2 organization has defined the specification of the media 
format [3gpp2]. Interoperability and conformance testing is done 
in cooperation with other bodies, including the Open Mobile 
Alliance (OMA) <http://www.openmobilealliance.org> and the 
International Multimedia Telecommunications Consortium (IMTC) 
<http://www.imtc.org/>. 
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Published specification: 
3GPP2 C.S0045, 3GPP2 C.S0050 [3gpp2] 
3GPP2 specifications are publicly accessible at the 3GPP2 web 
site, <http://www.3gqpp2.org>. 
Applications that use this media type: 
Multi-media 
Additional information: 
The type "audio/3gpp2" MAY be used for files containing audio but 
no visual presentation. Files served under this type MUST NOT 
contain any visual material. (Note that 3GPP timed text is 
visually presented and is considered visual material). 
Magic number(s): 
None. However, the file-type box must occur first in the file, 
and MUST contain a 3GPP2 brand in its compatible brands list. 
File extension (s): 
3g2 and 3gpp2 are both declared at <http://www.nist.gov/nics/>; 
3g2 is preferred. 
Macintosh file type code(s): 
r 3gp2’ 
Person & email address to contact for further information: 
H. Garudadri, hgarudadri@qualcomm.com 
Intended usage: 
COMMON 
Change controller: 
3GPP2 


3.2. Any Files 


The type "video/3gpp2" is valid for all files. It is valid to serve 
an audio-only file as "video/3gpp2". 


To: ietf-types@iana.org 
Subject: Registration of Standard MIME media type video/3gpp2 


MIME media type name: 


video 
MIME subtype name: 
3gpp2 
Required parameters: 
None 
Optional parameters: 
Codecs. See [Bucket]. If the video/3gpp2 body part contains 


another container format, the Codecs parameter MUST list all 

codecs indicated by all formats, including any contained formats. 
Optional parameter values: 

[3gpp2 ] 
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Encoding considerations: 
This data is binary and should be transmitted in a suitable 
encoding without CR/LF conversion, 7-bit stripping, etc.; base64 
is a suitable encoding. Note that this MIME type is used only 
for files; separate types are used for real-time transfer, such 
as for the RTP payload formats for H.263 [RFC2429] and 13K 
vocoder speech [RFC2658]. 

Security considerations: 
See the security considerations section in RFC 4393 (this 
document). 

Interoperability considerations: 
The 3GPP2 organization has defined the specification of the media 
format [3gpp2]. Interoperability and conformance testing is done 
in cooperation with other bodies, including the Open Mobile 
Alliance (OMA) <http://www.openmobilealliance.org> and the 
International Multimedia Telecommunications Consortium (IMTC) 
<http://www.imtc.org/>. 

Published specification: 
3GPP2 C.S0045, 3GPP2 C.S0050 [3gpp2] 


3GPP2 specifications are publicly accessible at the 3GPP2 web 
site, <http://www.3gqpp2.org>. 
Applications that use this media type: 
Multi-media 
Additional information: 
Magic number(s): 
None. However, the file-type box must occur first in the file 
and MUST contain a 3GPP2 brand in its compatible brands list. 
File extension(s): 
3g2 and 3gpp2 are both declared at <http://www.nist.gov/nics/>; 
3g2 is preferred. 
Macintosh file type code(s): 
r 3gp2 r 
Person & email address to contact for further information: 
H.Garudadri, hgarudadri@qualcomm.com 
Intended usage: 
COMMON 
Change controller: 
3GPP2 


4. IANA Considerations 


This document registers the MIME media types audio/3gpp2 and 
video/3gpp2, defined above. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2006). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at 
letf-ipr@ietf.org. 
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